Recently, groupware has come into wide use as software to enable cooperative working by a plurality of persons on a network. With such groupware, work efficiency and productivity can be improved, transmission speed increased, and so forth, by means of, for example, information transmission using e-mail or electronic bulletin boards, information sharing by means of group scheduling, and so forth, information analysis and arrangement via a main database, and the like.
A typical example of such groupware is “Notes/Domino” produced by Lotus Corporation of the USA. “Notes/Domino” is a client server system that runs on a network, and is provided with basic functions such as e-mail, a compound distribution document database, replication processing, and integration into a communication environment in a desktop environment. “Notes/Domino” is also provided with customization functions that allow a range from simple items oriented toward end-user development to high-speed items that perform programming to be used easily at high speed according to the particular purpose. In this way, it is possible for a developer to perform customization processing according to a particular purpose simply by means of incorporation into the “Notes/Domino” database without considering settings for a remote server and without having to worry about a client's type of machine.
In this way, effective processing is possible in accordance with organizational and other techniques by means of customization functions provided by “Notes/Domino” itself. On the other hand, problems arise in terms of design in “Notes/Domino” applications. There is no particular agreed method for verifying and evaluating these design problems, and at present design information in a database is checked and assessed one item at a time.
However, with a method whereby design information is checked and assessed one item at a time, work efficiency is poor and it is not possible to see the relationship between objects. Also, unless an explanation of the detailed contents is received from the developer, it is extremely difficult to grasp the problems and an overall picture of the database, and there is no alternative but to entrust the tasks of database verification and evaluation to the developer. Moreover, there have been many cases where a developer without in-depth experience of “Notes/Domino” development has created a database making full use of the “Notes/Domino” functions known to the developer at that point in time, without considering performance or maintenance, and performance has deteriorated after system testing or operation has begun.
Furthermore, with the application development/maintenance functions currently offered by “Notes/Domino”, there are cases where such problems arise from the difficulty of seeing design information, from not being able to reference design information from a variety of angles, and being able to obtain design information as a text file but finding it difficult to understand. As a result, debugging efficiency is poor, and progress, quality, and change management is difficult, with the result that group development is hindered and maintenance is difficult to carry out.
These problems are major causes of a deterioration in productivity and quality in “Notes/Domino” application development and maintenance.
Also, reference documentation concerning performance now exists, but it is difficult to identify causes of deterioration of performance with these reference documents, or to find effective improvement measures. Reasons for this include the following:                Although causes of deterioration are included in the reference documentation, the coverage is not of a sufficient level to enable the relevant reasons to be understood.        It is not possible to judge how bad the causes of deterioration are.        There are too many causes of deterioration, and it is not known which apply.        The stated improvement proposals are lacking in practical detail.        There is no way of checking the cause of deterioration of the relevant application.        There is material concerning performance, but it is not possible to ascertain which part of the relevant application has an effect.        
Moreover, when performance is poor, in many cases a request for improvement comes from top management in a top-down fashion, and it is necessary to conduct an investigation into causes of deterioration of performance, and draw up proposals for improvement, in a short time, and to implement solutions quickly. In most cases, therefore, a developer is not given enough time to conduct recurrence testing, read the reference documentation, and investigate proposals for improvement.
Meanwhile, development of applications using Java is increasing (Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both). However, since developers are as yet inexperienced in Java, the programs they write have many problems. Also, in development using Java, performance problems and memory leak problems are often identified at the stage at which load testing is carried out, and program changes are often carried out of necessity in the latter half of the development schedule.
In order to solve these problems, a program review needs to be conducted at an early stage, but there are not enough people capable of conducting a review. At present, a review involves the following:                Obtaining the program code subject to review,        Implementing the review,        Collating the results of the review and preparing a report,        Sending the report to the developer, and        Conducting a questionnaire as to whether or not the analysis results are valid.        
By automating this series of workflow steps, it is possible to achieve a reduction in workloads and solve the problem of lack of personnel.
However, automating the above described workflow involves problems such as the following:                If a review is conducted using an analysis tool, automation will be promoted, but there is a limit to the problems that are revealed automatically by an analysis tool, and not all problems can be brought to light.        With manual analysis, there will be variations in the level of analysis according to differences in the skill of individuals. At present, most problems found by manual analysis are of known patterns. However, as conditions are complex, it is not possible to use tools, and so forth        Normally, a review is carried out by a plurality of personnel, and there is the task of collecting the results into a single format.        